System and method for providing remote data access and transcoding for a mobile communication device

ABSTRACT

A system for providing information content over a network to a mobile communication device includes a transcoding system and a first network device. The transcoding system includes a plurality of transcoders. Each transcoder is operable to transcode the information content from a respective input content type into a respective output content type. The first network device is in communication with the transcoding system and includes a connection handler system. The first network device is operable to receive a first connection request that includes transcoder request data and to select a corresponding connection handler. The connection handler is operable to select one or more transcoders from the plurality of transcoders based on the transcoder request data.

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims benefit of the following United StatesProvisional Applications: Serial No. 60/305,044, entitled “System AndMethod For Providing Remote Data Access For A Mobile CommunicationDevice” and filed on Jul. 12, 2001; Serial No. 60/327,752, entitled“System and Method For Providing Remote Data Access To A MobileCommunication Device” and filed Oct. 9, 2001; Serial No. 60/330,604,entitled “System And Method For Providing Remote Data Access AndTranscoding For A Mobile Communication Device” and filed Oct. 25, 2001;and Serial No. 60/340,839, entitled “System And Method For Pushing DataFrom An Information Source To A Mobile Communication Device” and filedDec. 19, 2001. The complete disclosures of all of the above-identifiedprovisional applications are hereby incorporated into this applicationby reference.

[0002] This application is also related to the following co-pendingNon-Provisional Applications: Ser. No. __/____, entitled “System AndMethod For Providing Remote Data Access For A Mobile CommunicationDevice” and filed on ______, 2002; and Ser. No. __/____, entitled“System And Method For Pushing Data From An Information Source To AMobile Communication Device” and filed on ______, 2002, the completedisclosures of which are hereby incorporated into this application byreference.

BACKGROUND

[0003] 1. Field of the Invention

[0004] This invention relates generally to mobile communications, and inparticular to providing access to remote data from mobile communicationdevices.

[0005] 2. Description of the State of the Art

[0006] Known solutions for providing remote access to data using mobilecommunication devices tend to be relatively limited. For example,Wireless Application Protocol (WAP) browsers for mobile devicestypically provide access only to information associated withWAP-compliant sources. Although other known and similar products mayallow a mobile device user to access further information sources, suchproducts generally do not make efficient use of mobile communicationnetwork resources, particularly wireless communication links, and oftenrequire processor-intensive operations such as information parsing to beexecuted on the device.

[0007] Furthermore, most known data access systems and methods are notis suited to provide truly secure access to confidential informationstored on private networks, such as corporate information located on adata store behind a security firewall.

SUMMARY

[0008] The instant application describes a system and method forproviding mobile communication devices with access to remote informationsources. A system and method for providing secure access to confidentialinformation is also described.

[0009] The systems and methods described herein provide for access toany of a plurality of types and formats of information. Particularinformation translation operations may be selected by either a mobilecommunication device or an information source and performed on aninformation source side of a mobile communication system. This not onlyreduces the complexity of device processing operations and any devicehardware and software components associated with such operations, butalso provides for customized device information formats.

[0010] In one embodiment, a system for providing information contentover a network to a mobile communication device includes a transcodingsystem and a first network device. The transcoding system includes aplurality of transcoders. Each transcoder is operable to transcode theinformation content from a respective input content type into arespective output content type. The first network device is incommunication with the transcoding system and includes a connectionhandler system. The first network device is operable to receive a firstconnection request that includes transcoder request data and to select acorresponding connection handler. The connection handler is operable toselect one or more transcoders from the plurality of transcoders basedon the transcoder request data.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011]FIG. 1 is a general block diagram of a communication system thatprovides access to a remote information source from a mobilecommunication device.

[0012]FIG. 2 is a more detailed block diagram of the system shown inFIG. 1.

[0013]FIG. 3 is a flow chart representing general connectionhandler-related operations in the system.

[0014]FIG. 4 is a flow chart of connection handler data processingoperations.

[0015]FIG. 5 is a signal flow diagram illustrating an example ofdevice-controlled transcoder selection for an HTTP connection.

[0016]FIG. 6 is a signal flow diagram representing device-controlledtranscoder selection with extension of accepted content types.

[0017]FIG. 7 is a signal flow diagram of an example of server-controlledtranscoder selection for an HTTP operation .

[0018]FIG. 8 is a general block diagram of a communication system withan external transcoder system.

[0019]FIG. 9 is a signal flow diagram illustrating an example ofdevice-controlled transcoder selection for an HTTP connection with anexternal transcoder system such as shown in FIG. 8.

[0020]FIG. 10 shows a further signal flow diagram for an externaltranscoder system.

[0021]FIG. 11 is a block diagram showing an IP Proxy system implementedin a secure network.

[0022]FIG. 12 is a signal flow diagram illustrating a corporate dataaccess operation.

DETAILED DESCRIPTION General System Description

[0023]FIG. 1 is a general block diagram of a communication system thatprovides access to a remote information source 20 from a wireless mobilecommunication device (“mobile device”) 12. In FIG. 1, the system 10includes a mobile device 12, a wireless network 14, a gateway 15, a widearea network (WAN) 16, an Internet Protocol (IP) Proxy system 18, and aninformation source 20. Although an IP Proxy system 18 is shown in theillustrative example system of FIG. 1, proxy systems for protocols otherthan IP may be implemented in accordance with the present invention.Protocols at other levels within the Open Systems Interconnection (OSI)model can also be proxied using this system. Such other protocolsinclude but are not limited to Hypertext Transfer Protocol (HTTP) andTransmission Control Protocol (TCP).

[0024] The mobile device 12 may be any mobile device adapted to operatewithin a wireless communication network 14, and is preferably a two-waycommunication device. The mobile device 12 may have voice and datacommunication capabilities. Depending on the functionality provided bythe mobile device 12, the mobile device 12 may be referred to as a datamessaging device, a two-way pager, a cellular telephone with datamessaging capabilities, a wireless Internet appliance or a datacommunication device (with or without telephony capabilities). As willbe apparent to those skilled in the field of communications, theparticular design of a communication subsystem within the mobile device12 will be dependent upon the communication network 14 in which themobile device 12 is intended to operate. For example, a mobile device 12destined for a North American market may include a communicationsubsystem designed to operate within the Mobitex™ mobile communicationsystem or DataTAC™ mobile communication system, whereas a mobile device12 intended for use in Europe may incorporate a General Packet RadioService (GPRS) communication subsystem. Those skilled in the art willalso appreciate that other types of mobile devices and networks are alsocontemplated. The inventive systems and methods described herein may beimplemented in conjunction with virtually any wireless network 14.

[0025] The gateway 15 shown in FIG. 1 provides an interface between thewireless network 14 and a WAN 16, which may, for example, be theInternet. Such functions as mobile device addressing, conversion of databetween WAN protocols and wireless network protocols, storing andforwarding data to and from the mobile device 12, and other interfacefunctions may be performed by the gateway 15.

[0026] It is also possible that an IP Proxy system 18 could be hosted bya network carrier/operator associated with the wireless network 14. Inthis case, the connection between the IP Proxy system 18 and the gateway15 would use a private network of the carrier instead of the WAN 16. TheWAN could then be used to communicate between the IP Proxy system 18 andthe information source 20.

[0027] The IP Proxy system 18 is a system that effectively provides themobile device 12 with access to the information source 20 and isdescribed in further detail below. Through the IP Proxy system 18, themobile device 12 may access any information source 20, such as anInternet or web server, that can communicate with the IP Proxy system18. The information source 20 therefore requires no special applicationsor protocol support for wireless network communications, since itcommunicates with the IP Proxy system 18 and not directly with themobile device 12. Although shown in FIG. 1 as a direct connection, theIP Proxy system 18 and information source 20 may also communicatethrough a network such as a local area network (LAN) or WAN, includingthe Internet.

[0028] Wireless networks and the Internet use similar addressingschemes, in which recipients, such as mobile devices in a wirelessnetwork or Internet-connected computers, are identified by numericaladdresses. For example, mobile devices are identified in the Mobitexnetwork using Mobitex Access Number (MAN) and public Internet nodes areidentified using an IP address scheme. However, differences betweenwireless network and Internet transport mechanisms prevent directcommunication between information sources 20, the vast majority of whichare Internet-based, and mobile devices 12. Furthermore, informationsource content is largely targeted to desktop or other computer systemswith relatively powerful processors and may require thatprocessor-intensive operations such as information parsing be performedby a recipient. Since mobile devices tend to have less powerfulprocessors, these operations take more time on such mobile devices thanon computer systems and can consume significant amounts of power fromnormally limited-power sources. The IP Proxy system 18 bridges the gapbetween Internet-based and possibly other information sources 20 and awireless network 14 with associated mobile devices 12. The servicessupported by the IP Proxy system 18 may include address mapping, contenttransformation and verification, and protocol mapping and optimisation,for example.

Detailed Description of the IP Proxy System

[0029]FIG. 2 is a more detailed block diagram of the IP Proxy system 18shown in FIG. 1. The IP Proxy system 18 may include a dispatcher 22, aTCP handler 24, an HTTP handler 26, a transcoding system 28, one or morepush services generally designated 30, a state persistence element 34, amonitoring system 36, and a logging system 38. FIG. 2 also shows a pushserver 42, a web server 46, a web browser 48, and a file system 40, withwhich the IP Proxy system 18 may interact from time to time. Many of thecomponents shown in FIG. 2 may be implemented primarily as computersoftware modules. Elements within the IP Proxy system 18 will typicallybe running on the same computer, whereas components external to the IPProxy system 18 are normally resident on separate computers. In anotherembodiment, however, the elements of the IP Proxy system 18 may insteadbe distributed among a group of computers distributed over a network.

[0030] Dispatcher 22 manages data flows and the connection to thegateway 15. Depending on the type of connection or the type of databeing transferred or data transaction being performed for example, thedispatcher 22 interacts with the TCP handler 24 or the HTTP handler 26.The transcoding system 28 comprises one or more data filters, each ofwhich converts data or other information from one format into a formatthat can be processed by a mobile device 12.

[0031] Push services 30 provide for transfer of “unsolicited”information from an information source such as push server 42, which mayfor example be a web server or a software application, to a mobiledevice 12 through the IP Proxy system 18. The push services component 30allows the push server 42 to address the mobile device 12 using forexample the email address of the mobile device owner or some otherconvenient label. Accordingly, the push server 42 need not know theaddress of the mobile device 12 in the wireless network 14. The statepersistence element 34, in conjunction with a data file system 40 or adatabase, enables management of cookies, passwords and possibly otherstate information associated with web servers 46 to which the IP Proxysystem 18 may connect. It preferably stores state information about aconnection that persists between discrete network packets, such as anHTTP request/response pair. The monitoring system 36 allows remotemonitoring of the performance, efficiency, usage and health of an IPProxy system 18 by an administrator through an interface such as a webbrowser 48. As its name implies, the logging system 38 may be configuredto store usage, connection, user statistics and the like to the filesystem 40 or some other secondary storage.

Connections and Handlers

[0032] The IP Proxy system 18 can preferably handle and process contentfrom various information sources 20, including Internet-based sources.This functionality is provided by connection handlers, which areintermediate objects that have the ability to process content frominbound and outbound connections to an IP Proxy system 18. In the IPProxy system 18 shown in FIG. 2, two such handlers, the TCP handler 24and the HTTP handler 26, are shown. These handlers can preferably bereplaced and customized or additional handlers can preferably be addedto an IP Proxy system 18 as needed. The connection handlers can optimisenot just the content but also the protocol. For example, some requeststhat would normally be sent to the mobile device (such as a request fora password) may be resolved by the connection handler, where requesteddata has been stored in the file system 40 or another store accessibleto the connection handler, through the state persistence element 34, forexample. This instance of a protocol optimisation can adapt so-called“chatty” protocols to be more wireless friendly by reducing the amountof traffic sent over a wireless network to a mobile device, therebyreducing the effects of wireless network bandwidth constraints andlatency.

[0033] Outbound connections would be made from mobile devices 12 inorder to send data to and receive data from other entities such asInternet nodes. The IP Proxy system 18 preferably receives connectionrequests from mobile devices 12 using a particular protocol, such as aproprietary protocol called IP Proxy Protocol or IPPP developed by theassignee of the present application. Other protocols might also be used.The IP Proxy system 18 then establishes an Internet connection,according to routing information provided by the mobile device 12, andtranslates and maps that connection to start forwarding data in bothdirections. A filtering or transcoding process is invoked whenevernecessary, based on the type of content being passed over theconnection, or based on a particular transcoding process specified inthe connection request from the mobile device 12, for example. Suchoutbound connections will be described in further detail below, in thecontext of web browsing operations.

[0034] Inbound connections are used, for example, to implement a datapush model. In this model, a mobile device 12 may be sent informationwithout having issued requests to fetch the information, as is the casewith outbound connections. As described briefly above, mobile devices 12may exist on a different network domain than Internet nodes. The IPProxy system 18 is responsible for bridging the Internet and wirelessnetwork domains. Thus, the IP Proxy system 18 requires certain routinginformation to route the traffic to a particular mobile device 12. In apush operation, at least some of this routing information must beprovided by the Internet node, such as the push server 42, that issuesthe request to establish an inbound connection. The IP Proxy system 18may convert commonly known addressing schemes such as email or IPnumbers into the appropriate wireless network address of an intendedrecipient mobile device 12. In another embodiment, a transcoding processfor pushed content may be selected and specified by a push server 12 orinformation source 20.

[0035] Connection handlers in an IP Proxy system 18 are stream-basedobjects. When an outbound or inbound connection is requested, a virtualpiped stream is established between mobile device 12 and the appropriateconnection handler. The connection handler will be instantiated andstarted to process the content for the established connection. Loadingthe connection handler is based on a connection request, whichpreferably contains a reference to appropriate handler name that impliesthe type of the traffic that would normally go through the virtual pipedstream and the location of the handler that must be loaded if is notalready loaded. The functions of connection handlers include mappingInternet or other information source-side connections and mobiledevice-side connections, forwarding traffic between these connections,and loading and invoking the appropriate transcoders on informationdestined for a mobile device 12.

[0036] Every connection is preferably associated with an instance of aconnection handler. This is true even for a connection that does notrequire that content be processed by the IP Proxy system 18, such as apure TCP connection between a mobile device 12 and a server. This typeof connection handler forwards content back and forward without makingany sort of modification to the content, although it may makemodifications to the protocol. For clarity, those skilled in the artwill appreciate the distinction between the data or content (what themobile device requested or is being sent) and the protocol (the“wrappers” and conversions required to deliver the data).

[0037] Connection handlers are also responsible for loading theappropriate content filters or transcoders. According to one embodiment,a connection handler such as the HTTP connection handler 26 uses aparticular transcoder in the transcoder system 28 specified by eitherthe mobile device 12 or an information source such as push server 42 orweb server 46.

[0038]FIG. 3 is a flow chart representing general connectionhandler-related operations in an IP Proxy system. At step 50, the IPProxy system 18 receives a connection request, which as described abovemay relate to an inbound connection or an outbound connection. When theconnection is associated with a particular handler, such as an HTTPconnection that requires HTTP connection handler 26, the appropriatehandler is loaded and executed at step 54 and the connection isestablished, as indicated at step 58. If the request is outbound (fromthe mobile device 12), then the dispatcher 22 examines the protocol typeassociated with the request and delegates the connection to theappropriate handler. Data may then be exchanged between a mobile device12 and an Internet service, push server 42, web server 46 or otherinformation source 20.

[0039] If certain connection handlers are used for a connection, such asfor a pure TCP connection as described above, then the data may passthrough the IP Proxy system 18 unchanged. In some IP Proxy systemshowever, content sent over a TCP handler may be modified. When otherconnection handlers are used however, data destined for a mobile device12 may need to be converted into a suitable format. FIG. 4 is a flowchart of connection handler data processing operations. At step 62, datadestined for a mobile device 12 is received. Although labelled as aresponse from a connection, following an information request from amobile device 12, for example, it will be understood that data receivedby the connection handler may instead be information to be pushed to themobile device 12 from a push server such as 42 via push service 30. Theconnection handier determines at step 64 if transcoding is required. Ifnot, then the information is sent to the mobile device at step 70.Otherwise, the appropriate transcoder is loaded and executed as shown instep 66, and the data is transcoded into an acceptable format as shownin step 68, before being sent to the mobile device 12. In oneembodiment, the entity that initiates the communication, the mobiledevice for fetched data or the push server 42 for pushed data, canspecify a particular transcoder to do the transcoding of the fetched orpushed data, as described in more detail below.

[0040] A connection handler may be implemented in computer software as aJava™ class file, placed in a certain directory in a file system suchthat an IP Proxy system Java Virtual Machine (VM) may locate and loadthe file when needed or requested. As those skilled in the art willappreciate, Java uses CLASSPATH environment variable as a guide to whereit should perform a lookup for user defined classes. In one embodiment,the paths to connection handlers are among the first listed paths in theCLASSPATH so that they are loaded relatively quickly when requested. Theconnection direction (inbound or outbound) and the name associated witha connection handler may also play a role in defining the full classname of a handler. Another embodiment utilizes dynamic linked libraries(DLLs) or dynamic shared objects (DSOs) depending on the targetoperating system.

[0041] Most connection handlers will normally be associated with a namethat represents a protocol at the application layer. For example, if amobile device 12 is enabled with a web browser and may therefore requestto open connection to an Internet server such as 46, it would beappropriate to have HTTP as a name for that connection handler,illustratively HTTP connection handler 26. In one embodiment, thehandler name adheres to the known rules of naming packages in Javalanguage. Preferably, the handler name is in lower case; however, froman IP Proxy system point of view, naming convention does not matter,provided the Java VM can load that connection handler. Any ConnectionHandler may also have its class name as Handler.class. An example of aValid full class name that represents a connection handler is asfollows:

[0042] net.rim.protocol.iplayer.connection.handler.<connectiondirection>.<connection handler name>.Handler.class

[0043] where connection direction can be either device, which impliesoutbound connection, or server, which implies inbound connection.Connection handler name is the name associated with the handler, forinstance, http, ftp, etc.

[0044] There are at least two ways that an information source such as anInternet node can establish a connection to a mobile device through theexample IP Proxy system 18 shown in FIG. 2: (1) using a transportationlayer protocol directly, such as TCP, to open a direct connection to theIP Proxy system 18, or (2) using a datagram protocol at the applicationlayer, such as HTTP. The IP Proxy system 18 includes two correspondingconnection handlers, which may, for example, represent a basic IP Proxysystem that can process two of the most common types of connection. Thefirst is the TCP connection handler 24, associated for example with thename tcp. The second is the HTTP connection handler 26, which maysimilarly be associated with the name http, as described above. Inaddition to supporting common connection types, these connectionhandlers may also satisfy requirements for Mobile Information DeviceProfile (MIDP) implementation at the mobile device 12. However, the IPProxy system 18 and the mobile device 12 can be extended to support anyother types of connections. In the IP Proxy system 18, connectionhandlers may possibly be added by providing an application programminginterface (API) in the IP Proxy system 18 and developing new connectionhandlers that adhere to the API, for example.

[0045] In one embodiment, the IP Proxy System 18 includes connectionhandlers that are loaded from a local storage medium, for example a diskdrive associated with a computer on which IP Proxy system software isrunning. In another embodiment, the connection handler storage may alsoor instead be remote from the IP Proxy system 18, such as in a storagemedium accessible by the IP Proxy system 18 through a LAN connection oreven a WAN like the Internet. This allows sharing of a single directoryof connection handlers among all IP Proxy systems 18 that cancommunicate with the connection handler store. It would also be possibleto have third parties extend the connection handler set by embedding theURL where the connection handier java class can be found.

[0046] If connected to the Internet, a connection handler directorycould potentially be accessed and thus shared by all Internet-connectedIP Proxy systems 18. Public Internet-connected connection handlerdirectories would preferably receive connection handler requests from IPProxy systems and in response transmit any requested connection handlersto the requesting IP Proxy system 18. A new connection handler may berequired by an IP Proxy system 18 when a mobile device 12 whichcommunicates with the IP Proxy system 18 downloads a new softwareapplication or invokes a new mobile device feature which uses a newconnection scheme or a connection method that was not previously used bythe mobile device 12. A mobile device user or the new application orfeature may then send a control message to the IP Proxy system 18,indicating for example the name of the required connection handler,perhaps the mobile device application that requires the new connectionhandler and an address associated with a connection handler directoryfrom which the new connection handler may be requested. The IP Proxysystem 18 would then preferably request the new connection handler fromthe directory. A connection handler directory could be implemented forexample as a web server accessible to an IP Proxy system 18 using HTTPrequests.

[0047] When a connection handler is loaded from a remote source, the IPProxy system 18 preferably stores the handler in a local store in orderto provide for faster loading of the handler for subsequent operationsinvolving the corresponding type of connection for either the mobiledevice 12 for which the connection handler was initially loaded from thedirectory or a different mobile device 12 supported by the IP Proxysystem 18. Depending upon the memory resources available to an IP Proxysystem 18, downloaded connection handlers may be stored indefinitely orfor a particular period of time. Alternatively, a least recently used orLRU replacement scheme could be used to provide for more efficient useof available memory by overwriting relatively less frequently usedconnection handlers when new handlers are downloaded. Other memorymanagement techniques could also be used to optimize local IP Proxysystem connection handler storage arrangements.

Transcoding

[0048] Relative to computer networks such as the Internet, wirelesscommunication networks are slow. Any program that bridges the two, as anIP Proxy system does, may have to transform Internet data so that it isformatted appropriately for a wireless network and mobile device. Thisprocess is referred to herein as filtering or transcoding, and usuallyinvolves such operations as compressing data from the Internet into amore compact format appropriate for wireless transmission.

[0049] In the following description, transcoding operations areillustrated primarily in the context of the above example of an HTTPhandler 26 and HTTP connection. The HTTP connection and handler exampleis particularly useful in that HTTP allows content tags in the form ofMultipurpose Internet Mail Extension (MIME) types, which may be used insome embodiments to determine an appropriate transcoder for receivedinformation.

[0050] In an IP Proxy system 18, there may be a single configurationfile for each type of connection handler. In the IP Proxy system 18 forexample, a single configuration file associated with the HTTP connectionhandler 26 may include information for all HTTP content transcoders.This configuration file is used to map transcoders to certain keys. TheIP Proxy system 18 may consult this file to determine which contenttranscoders are available to manipulate any received content destinedfor a mobile device 12.

[0051] In the configuration file, general rules are preferably specifiedfor how to define the mapping between content types and transcoders. Oneexample of a possible configuration file entry is as follows: Entry ={[default] : { RSV | <Transcoder name>}} | { [[ InputType] | <->OutputType> ] :  [ Transcoder name] }

[0052] where

[0053] default indicates to the IP Proxy system which default transcodershould be loaded in case there is no one transcoder associated with areceived content type or connection request;

[0054] RSV is a set of reserved keywords that is used in configurationfile, such as pass (i.e. forward data to the mobile device withouttranscoding) or discard (i.e. do not transcode or forward data to themobile device);

[0055] Transcoder name is the name of the mapped transcoder;

[0056] InputType indicates the input content type that the mappedtranscoder can accept, which for an HTTP transcoder configuration filemay be a MIME type; and

[0057] OutputType indicates the output type, such as a MIME type for anHTTP transcoder that the transcoder can produce.

[0058] By using a content transcoder configuration file, new transcodersmay be added for use by an IP Proxy system 18. Therefore, as newtranscoders are developed and become available, they can be added to theconfiguration file for any appropriate connection handlers and canthereafter be loaded by a connection handler when required, and withoutaffecting other components of the IP Proxy system 18. For example,configuration file entries may be added without shutting down the entireIP Proxy system 18, thus allowing dynamic expansion of data that can beconverted for transmission to mobile devices 12.

[0059] In another embodiment, a common configuration file format for allconnection handlers is used, and thus only a single configuration fileentry need be prepared and can be added to the configuration file forany connection handler. The concept of a common configuration fileformat for all connection handlers can be further extended to providinga single configuration file for an IP Proxy system 18. Such aconfiguration file could then be used by all connection handlers in theIP Proxy system 18 to determine which content transcoders are availableand to select a particular transcoder for received content. However, itshould be understood that a common configuration file format is in noway required. Some connection handlers may share a configuration fileentry format or even a single configuration file, whereas otherssupported by the same IP Proxy system 18 may have differentconfiguration files and entry formats.

[0060] The IP Proxy system 18 preferably loads and executes a particulartranscoder specified by either a mobile device or an information sourceto transcode data being either pushed to or pulled by a mobile device12. Several illustrative example content transcoder loading controlschemes are described in further detail below. Although these examplesrelate primarily to HTTP connections and handlers, other connectiontypes and handlers may use similar arrangements and methods to select atranscoder.

[0061] It should also be appreciated that a transcoder may instead beselected based upon information other than content types, includinginformation in a header portion or other portion of a connection requestfrom a mobile device, a response to a connection request, or acommunication from an information source including information to bepushed to a mobile device. For example, an IP Proxy system 18 may beconfigured to determine a type of the mobile device 12 to which data isto be sent. Transcoder selection by the IP Proxy system 18 couldsimilarly be based on a network address or other identifier of themobile device 12. Mobile device- or device type-dependent transcoderselection schemes may be supported by providing a device or device typemapping table accessible to the IP Proxy system 18, which maps devicesor device types to transcoders. Alternatively, a configuration file maybe adapted to include device or device type identifiers to therebyassociate particular transcoders with devices or device types.

[0062] In a similar manner, transcoders may be selected based on anaddress (such as a URL) or other identifier of an information source, toenable information source-specific transcoding. A mapping table or aconfiguration file accessible to an IP Proxy system such as 18, may beused to enable transcoder selection based on information source. Thistype of transcoder selection may be useful, for example, when aparticular transcoder is to be used to transcode any content thatoriginates from a specific website and is destined for a mobile device.

[0063] Although the primary type of transcoder selection schemedescribed below is based on a particular transcoder specified by amobile device or information source, any of these alternative schemesmay be used to select a transcoder, for example, when a specifiedtranscoder is not available. If information content to be sent to amobile device includes multiple content types, then these schemes mayalso be used to select a transcoder for one or more of the multiplecontent types.

Specifying a Content Transcoder from a Mobile Device

[0064] A connection request from a mobile device 12 may specify that aparticular transcoder be used to transcode any content received inresponse to the request. For an HTTP connection for example, an IP Proxysystem 18 may be configured to expect a Content-Transcoder field in anHTTP request header to indicate that a mobile device 12, or typically anapplication on the mobile device 12, is specifying a particular HTTPcontent transcoder. The IP Proxy system 18 will load and execute thespecified transcoder to manipulate any response to the request. Theactive connection handler in the IP Proxy system 18, the HTTP connectionhandler 26, may also modify the request to include an indication, suchas a MIME type, of the type of content that can be accepted in responseto the request. The Content-Transcoder header field should have a valuethat is valid in the context of the HTTP configuration file, or whereanother connection handler is used, its corresponding configurationfile.

[0065] If a requested transcoder is not available, then an error messagewill preferably be sent back to mobile device 12, for example in theform of an IOException indicating that the requested transcoder is notavailable. The mobile device application or user may then have theoption to retry the request with a different transcoder. When therequested information is intended for a mobile device softwareapplication that requires information in a particular format availableonly from the specified transcoder however, the request may instead beretried at a later time when the specified transcoder may possibly beavailable.

[0066] Transcoder selection in a mobile device information request willnow be described in further detail by way of several illustrativeexamples of HTTP requests. FIG. 5 is a signal flow diagram illustratingan example of mobile device-controlled transcoder selection for an HTTPconnection. Although FIG. 5 shows only those components of the IP Proxysystem 18 directly involved in the example of an HTTP request from amobile device 12, other system components may also be present. In orderto avoid congestion in the drawings however, such components as 30through 48 in FIG. 2 have not been shown in FIG. 5.

[0067] In FIG. 5, an HTTP request is sent from the mobile device 12,through a wireless network and possibly through a WAN and appropriategateway to the IP Proxy system 18. As described above, the mobile device12 may communicate with an IP Proxy system 18 using a protocol otherthan HTTP, such as the proprietary IPPP. In such arrangements, althoughthe connection request conforms to a particular protocol, the requestmay specify a connection type or connection handler, HTTP in thisexample, associated with a different protocol. Therefore, references toHTTP requests sent from a mobile device 12 should be interpreted toinclude both HTTP requests, if mobile device to IP Proxy systemcommunications are via HTTP, as well as connection requests whichconform to other protocols but specify HTTP or HTTP connection handlersand thus are interpreted by an IP Proxy system 18 as HTTP requests.

[0068] The request from the mobile device 12 is received by thedispatcher 22, which interprets the request as an HTTP request and loadsthe HTTP handler 26. Preferably in a header field, such as theContent-Transcoder field referred to above, the request in this examplespecifies that a particular transcoder which converts from WirelessMarkup Language (WML) content to a tokenized, compressed version of WMLgenerally referred to as Compiled WML or simply WMLC, should be used totranscode any content received in response to the request. The requestmay also include an indication of the type of content, WMLC in FIG. 5,that the mobile device is configured to accept. Since the IP Proxysystem 18 may determine or infer the content type(s) accepted by themobile device 12 from the output type of the specified transcoder,accepted content types need not necessarily be specified in the requestfrom the mobile device 12.

[0069] The example request shown in FIG. 5 specifies the particulartranscoder in terms of its input content type (WML) and output contenttype (WMLC). However, other transcoder naming conventions are alsopossible. When a configuration file (72 in FIG. 5) has entries in aformat as described above, part of the file entry for each transcoderindicates its respective input and output content types. The “TranscoderName” field in such a configuration file entry therefore need notnecessarily also include the input and output content types. Althoughmany different transcoder naming schemes are possible, a particulartranscoder is preferably specified in any mobile device requests andconfiguration files using the same name.

[0070] Regardless of the transcoder naming scheme, the HTTP handler 26preferably uses the specified transcoder name, WML→WMLC in FIG. 5, toperform a lookup in the configuration file 72, shown in the transcodingsystem 28. It should be appreciated however, that the configuration file72 might instead be external to the transcoding system 28, part of theHTTP handler 26, or even external to the IP Proxy system 18 providedthat the HTTP handler 26 can access the file. In most implementations,the configuration file 72 will be stored in a data store accessible bythe IP Proxy system 18, typically on the same computer system on whichthe IP Proxy system 18 is running.

[0071] The HTTP handler 26 searches the configuration file 72 todetermine if the transcoder specified in the request is available in theIP Proxy system 18. Where the transcoder input content type is notinferable from the transcoder name or specified in the request from themobile device 12 as in FIG. 5, the transcoder input content type ispreferably available from the configuration file 72. In FIG. 5, theconfiguration file 72, which may, for example, be implemented as alookup table, includes entries for two transcoders, the specifiedWML→WMLC transcoder and an HTML→WMLC transcoder. Since the WML→WMLCtranscoder specified in the mobile device request has an entry in theconfiguration file 72 and is therefore available to the IP Proxy system18, the HTTP handler 26 prepares an HTTP request including the inputcontent type of the transcoder, WML, as an accepted content type andsubmits the HTTP request to the web server 76. If the specifiedtranscoder is not available in the IP Proxy system 18, then the HTTPhandler 26 returns an error message to the mobile device 12, through thedispatcher 22 or other protocol translator if necessary, indicating thatthe required transcoder is not available. Alternatively, the dispatcher22 may perform the configuration file lookup operation and return theerror message to the mobile device 12.

[0072] In response to an HTTP request from the IP Proxy system 18, theweb server 76 returns requested content, in WML format in the example inFIG. 5, to the IP Proxy system 18. The HTTP handler 26 then determinesthat the returned content is WML, loads the WML→WMLC transcoder 74specified in the mobile device request from a local store for example,and executes the transcoder to convert the received content into WMLC.The WMLC content is then forwarded to the mobile device 12, through thedispatcher 22.

[0073] Although FIG. 5 shows the response to the mobile device 12 beinghandled by the dispatcher 22, similar protocol translation or conversionbetween HTTP used by the handler 26 and a communication protocol used bythe mobile device 12 may instead be performed by the HTTP handler 26 oranother protocol translation/conversion module in the IP Proxy system18.

[0074] In the event that content is returned to the IP Proxy system 18in other than the requested content type, an error message is preferablyreturned to the mobile device 12 and possibly the information source,web server 76, indicating that the request could not be completed asspecified. Alternatively, if the returned content cannot be convertedusing the specified transcoder, then the HTTP handler 26 may search fora transcoder to transcode the received content into a content type thatcan be transcoded by the requested transcoder. The default transcoder ora different transcoder having an input content type and an outputcontent type respectively corresponding to the received content type andthe content type accepted by the mobile device 12 may instead be used.When content is returned in the mobile device-acceptable format, WMLC inthe example of FIG. 5, the content may be forwarded to the dispatcher 22without transcoding. Any time the specified transcoder could not be usedto transcode returned content, however, the mobile device 12 ispreferably informed that the request was not completed as specified, andpossibly which transcoder was used instead of the specified transcoder.

[0075] Since the mobile device 12 specifies a particular transcoder tobe used to transcode content returned from an information source inresponse to a request, control of any subsequent transcoding operationswhen the specified transcoder is not available may also be passed to themobile device 12. For example, when the transcoder configuration file 72does not include an entry for the specified WML→WMLC transcoder or thereturned content is not of the transcoder's input content type, the IPProxy system 18 may send a message to the mobile device 12 indicatingthat the specified transcoder is not available or cannot be used. Themobile device 12, a mobile device software application associated withthe request, or a mobile device user may then respond to the messageindicating the action to be taken. This action may include, for example,forwarding the content to the mobile device 12 without transcoding,invoking the default transcoder, invoking a different particulartranscoder specified by the mobile device 12, software application oruser, or discarding the content. The IP Proxy system 18 may alsodetermine which if any of the transcoders with corresponding entries inthe configuration file 72 may transcode the received content into eitherthe output content type of the transcoder specified in the request orother content types, and identify such available transcoders in themessage sent to the mobile device 12. The mobile device 12, softwareapplication or user may then use this information to determine if any ofthe available transcoders should be used to transcode the receivedcontent. For instance, if returned content cannot be transcoded by thespecified transcoder into a format required for particular processingoperations at the mobile device 12, but a second transcoder is availableto transcode the returned content into a content type that can be viewedon the mobile device 12, then a user may specify that the returnedcontent should be transcoded using the second transcoder and thetranscoded content should be forwarded to the mobile device 12. Althoughthe originally intended processing operations might not be possibleusing content that was transcoded using the second transcoder, the useris able to at least view the content.

[0076] In order to avoid sending connection requests that specifyunavailable transcoders, it may be desirable for the mobile device 12 toquery the IP Proxy system 18 for a list of available transcoders priorto issuing a connection request. A connection request can then beprepared using one of the transcoders known to be available to the IPProxy system 18. If a required transcoder is not available at an IPProxy system 18, then the mobile device 12 may query other IP Proxysystems in an attempt to find the required transcoder, prepare aconnection request specifying an alternate but available transcoder orabort an information request operation involving the requiredtranscoder.

[0077] It is contemplated that a specified transcoder may, for example,be associated with a particular mobile device software application orfunction and therefore is configured to output content in a formrequired by the software application. The content types output by suchtranscoders may be common types, such as WMLC in the above example, butmay be adapted to certain displays, software application input formatsor software application- or mobile device-related attributes. As such, adefault or other transcoding operation may not produce content in aformat usable by the mobile device software application, and an IP Proxysystem 18 may therefore be configured to abort processing of a requestor to discard content returned from an information source if thespecified transcoder is not available. Such subsequent processing may becontrolled by the mobile device 12, a mobile device software applicationor a mobile device user, as described above.

[0078] In the example shown in FIG. 5, the transcoder configuration file72 includes entries for “mutually exclusive” transcoders, in the sensethat the output content type of each transcoder is not compatible withan input type of any other transcoder. In one embodiment, one or morefurther transcoders may be used to convert received content into aformat or type that may be accepted by the specified transcoder. Therequest sent by the IP Proxy system 18 to the information source,illustratively web server 76, may then be formatted to extend theaccepted content types to include the input content types of any of thefurther transcoders as accepted content types.

[0079]FIG. 6 is a signal flow diagram representing mobiledevice-controlled transcoder selection with extension of acceptedcontent types. As in FIG. 5, FIG. 6 shows only those components of theIP Proxy system 18 directly involved in an HTTP request from a mobiledevice 12 in order to avoid congestion in the drawings.

[0080] An HTTP request specifying a particular transcoder and anaccepted content type is sent from the mobile device 12 to the IP Proxysystem 18, possibly through one or more intervening networks andinterface components. As in the above example, the request is receivedby the dispatcher 22, which interprets the request as an HTTP requestand loads the HTTP handler 26. The HTTP handler 26 then consults theconfiguration file 78, searching not only for the specified transcodername, but also for entries associated with any transcoders that outputcontent types that may be input to the specified transcoder. Therefore,according to this embodiment, additional MIME types are appended to theheader Accept line of an HTTP request based not only on the specifiedtranscoder input type, but also on input types for other transcoders. InFIG. 6 for example, the HTTP handler 26, perhaps in a first search passthrough the configuration file 78, finds the specified WML→WMLCtranscoder entry. The HTTP handler 26 may then repeat the configurationfile search for any transcoders such as the HTML→WML transcoder thatconvert content into WML, which can be input to the specified WML→WMLCtranscoder, to thereby identify further content types that may beaccepted in response to the request. A chained transcoder 82 thatconverts HTML to WMLC may also be created from the HTML→WML and WML→WMLCtranscoders. The HTML→WML and WML→WMLC transcoders may also beseparately invoked. The configuration file search may be furtherrepeated by the HTTP handler 26, depending for example on acceptabledelays in HTTP request processing.

[0081] In order to avoid the delays and demand on processing resourcesassociated with such multiple search passes through a configuration file78, a transcoder content type lookup table is may be used. Whentranscoders are first installed in an IP Proxy system 18, acomprehensive mapping table is preferably constructed to map receivedcontent types to possible output content types. For example, in FIG. 6,a lookup table entry for the input content type of the specifiedtranscoder, WML in FIG. 6, would indicate that HTML can be convertedinto WML. The table might instead be organized into single- andchained-transcoding sections, whereby if only a single transcodingoperation is preferred, the single-transcoder part of the tableincluding an entry for the specified WML→WMLC transcoder would beaccessed. If further transcoding operations and the associatedprocessing operations and time delays are acceptable, then the HTTPhandler 26 may perform a lookup of the input content type of thespecified transcoder in a chained-transcoder section of the table.Preferably, the format of the transcoding configuration file may beadapted to represent just such a lookup table in order to speed up thesearch. This may be accomplished, for example, by specifying a pathbetween content types involving multiple transcoders.

[0082] The determination regarding whether or not multiple transcodingoperations will be permitted may be made by the HTTP handler 26 eitherbefore or after the table or configuration file lookup operation isperformed, before an HTTP request is sent to the web server 80, or evenafter the requested content is received from the web server 80. In theexample of FIG. 6, it is assumed for illustrative purposes that multipletranscoders may be invoked. The Accept line in the header of the HTTPrequest from the mobile device 12 is therefore expanded by the system 18to include HTML in addition to WML. As described above, the acceptedformats are preferably listed in order of preference. Since HTMLrequires two transcoding operations instead of the single transcodingoperation of the specified transcoder, WML is preferably listed beforeHTML in the Accept line of the HTTP request sent from the IP Proxysystem 18 to the web server 80. It is also feasible for the chain oftranscoders to include both local and remote transcoding services. Theseremote transcoding services could be transcoder files that the IP Proxysystem 18 discovers, downloads and executes or they could be externaltranscoding services which receive data in one format and return it inanother.

[0083] The web server 80 then returns the requested content, in HTMLformat in the example in FIG. 6, to the IP Proxy system 18 in responseto the HTTP request. The HTTP handler 26 determines that the returnedcontent is HTML, loads and executes the HTML→WML transcoder and thenloads and executes the specified WML→WMLC transcoder on the WML resultof the first transcoding operation. The resultant WMLC content is thenforwarded to the dispatcher 22 and then to the mobile device 12. WhenWML content is returned by the web server 80, only the WML→WMLCtranscoder would be invoked. In the event that the specified transcoderis not available or the returned content is not one of the acceptedcontent types specified in the request from the IP Proxy system 18,request processing may either be aborted or proceed as described above.

[0084] A determination to allow or deny multiple transcoding operationsmay be based upon predetermined criteria such as maximum HTTP requestprocessing time or maximum content transcoding time or processor timefor example. This determination might also take a mobile deviceuser-specified priority into account. If high time priority (low timedelay) is assigned by the user to a submitted request, then singletranscoder operations may be selected. Alternatively, if a high datapriority is associated with a request, then any number of chainedtranscoder operations may be allowed in order to get the requested databack to the mobile device in an acceptable format. Multiple transcodersmay also be specified in the information request from the mobile device.Other criteria which may be applied by a connection handler include butare in no way limited to allowing chained transcoders only forrelatively small amounts of received content, only at certain times ofday, under specific current traffic conditions, or only when theconfiguration file or lookup table is stored in a local file system.Further or alternate criteria may be apparent to those skilled in theart and as such remain within the scope of the present invention.

[0085] It is also possible that more than one multiple-transcoder chainmay be available to convert between any two content types. In suchsituations, the IP Proxy System uses a priority scheme, based forexample on transcoding cost or fidelity, to select between severalavailable chains.

Specifying a Content Transcoder from an Information Source

[0086] A server or information push operation differs from informationrequest/response operations in that an information source sends contentto a mobile device 12 without first receiving a request to do so.Similar to the HTTP operations described above however, a particulartranscoder may be specified by an information source attempting to pushcontent to a mobile device 12. FIG. 7 is a signal flow diagram of anexample of server-controlled transcoder selection for an HTTP operation.As is above, FIG. 7 shows only those components of the IP Proxy systemdirectly involved in an HTTP-based server push.

[0087] In FIG. 7, content is pushed from the push server 42 to the IPProxy system 18. For an HTTP-based operation, the push may be an HTTPpost operation, in which the push server 42 submits a post request tothe IP Proxy system 18. The post request, similar to the HTTP requestdescribed above, encloses header fields in which at least a transcodername (WML→WMLC in this example) and possibly an indication of the typeof content, such as a MIME type of WML in FIG. 7, may be specified.Since the content is provided by the same entity that selects theparticular transcoder, the content type will normally be compatible withthe specified transcoder and therefore need not necessarily be specifiedin the post request.

[0088] The post request from the push server 42 is received by the pushservices module 30. In the example of FIG. 7, the push operation isHTTP-based, and the push services module 30 therefore invokes the HTTPhandler 26. It should be appreciated that different push services may beassociated with respective handlers in an IP Proxy system 18, and that asingle IP Proxy system 18 may provide several different push services.It is also contemplated that multiple push services modules may beassociated with a single connection handler. Alternatively, a singlepush services module may be functionally similar to the dispatcher 22and provide an interface between a push server 42 and any handler in anIP Proxy system 18. For the purposes of clarity however, only a singlepush services module 30 associated with the HTTP handler 26 is shown inFIG. 7.

[0089] The HTTP handler 26 preferably uses the transcoder name in thepost request, WML→WMLC in FIG. 7, to perform a lookup in theconfiguration file 72 to determine if the specified transcoder isavailable in the IP Proxy system 18. As in the preceding embodiments, aparticular transcoder is preferably specified in any post requests andtranscoder configuration files using the same name. In FIG. 7, an entryfor the transcoder specified in the post request exists in theconfiguration file 72. The WML→WMLC transcoder 74 is therefore availableto the IP Proxy system 18, and the transcoder 74 is loaded and executedto transcode the WML content enclosed in the post request into WMLCcontent. The WMLC content is forwarded to the mobile device 12, throughthe dispatcher 22. When content is provided by a push server in a mobiledevice-acceptable format, WMLC in the example of FIG. 7, the postrequest may specify a null or other predetermined value in anappropriate request header field to specify that the content should beforwarded to the dispatcher 22 without transcoding. It is alsocontemplated that a push services module 30 may be configured todirectly manage the transcoding of pushed content, instead of invoking aseparate connection handler.

[0090] If the particular transcoder specified in the post request fromthe push server 42 is not available to the IP Proxy system 18, then thepush operation may be aborted. Alternatively, a different transcoderhaving an input content type and output content type respectivelycompatible with the content from the post request and a content typeaccepted by the mobile device 12, if known to the IP Proxy system 18,may be used. Any time the requested transcoder could not be used totranscode pushed content, a push operation failure or error message maybe returned to the push server 42, particularly if the push server 42 isconfigured to retry undelivered content. When the default or any othertranscoder is used instead of the specified transcoder, then the pushserver 42 may be informed of the particular transcoder that was used.Any such alternate transcoding operations may instead be controlled bythe push server 42, which may, for example, specify another transcodername in response to a push operation failure or error indication messagereturned by the IP Proxy system 18. Since pushed content was notrequested by the mobile device 12, no such error or failure messagewould typically be sent to the mobile device 12.

[0091] If the transcoder specified by a push server 42 is associatedwith a particular mobile device software application or function orconfigured to output content in an application-specific format forexample, then alternate transcoders might not produce content in aformat usable by the mobile device application. As described abovehowever, a second transcoder may be available to transcode the contentfrom the push server 42 into a content type that can at least beprocessed in a certain way, to be displayed on the mobile device 12, forexample. In response to an error or failure message from the IP Proxysystem 18, the push server 42 may re-submit the content and/or specifythe second transcoder. The pushed content, although not suitable to beprocessed on the mobile device as originally intended, may thereby beviewed on the mobile device 12. The push server 42 may also set atranscoder substitution policy, such as no transcoder substitutionsallowed, chained transcoders allowed, etc.

[0092] The signal flow diagram of FIG. 7 shows a single contenttranscoder in a server data push via an HTTP post operation. It shouldbe apparent that a server may specify more than one content transcoder,to be used for example in a chained transcoding operation.

External Transcoder Systems

[0093] As described briefly above, transcoders may be loaded as neededfrom a local store on a computer system on which an IP Proxy system 18has been implemented. In another embodiment, transcoders may also beloaded from an external store. FIG. 8 is a general block diagram of acommunication system with an external transcoder system.

[0094] The system 90 shown in FIG. 8 is similar to system 10 of FIG. 1,except for the external transcoder system 86. Elements common to bothsystems 10 and 90 have been described above and are therefore describedonly briefly. As shown by the dashed lines in FIG. 8, the IP Proxysystem 84 may communicate with the transcoder system 86 through somesort of direct connection such as a serial port or connection, through aWAN 16 such as the Internet, or through a LAN 88 within which the IPProxy system 84 and the transcoder system 86 are configured to operate.Other communication links between the IP Proxy 84 and the transcodersystem 86 will be apparent to those skilled in the art.

[0095]FIG. 9 is a signal flow diagram illustrating an example of mobiledevice-controlled transcoder selection for an HTTP connection with anexternal transcoder system such as shown in FIG. 8. As in the precedingexamples, an HTTP request is sent from the mobile device 12 to the IPProxy system 84, specifying a particular transcoder (WML→WMLC) andpossibly indicating the content type, WMLC in this example, that can beaccepted at the mobile device 12. The request is received by thedispatcher 22 in the IP Proxy system 84, which determines that therequest is an HTTP request and thus forwards the request to the HTTPconnection handler 94. The HTTP handler 94 may be substantially similarto the HTTP handler 26 in FIG. 2 for example, although it operatessomewhat differently than handler 24 to load content transcoders. TheHTTP handler 94 receives the HTTP request from the mobile device 12 andmay then refer to a transcoder configuration file 92 or a lookup tableas described above to determine whether or not the specified WML→WMLCtranscoder is available to convert content received in response to therequest. If an entry corresponding to the specified transcoder is foundin the configuration file 92 or lookup table, then the HTTP handler 94sends a request to the appropriate information source such as web server76. Web server 76 processes the request from the IP Proxy system 84 andreturns WML content to the HTTP handler 94. These operations aresubstantially as described above in the preceding examples.

[0096] When the WML content is received by the HTTP handler 94, it ispreferably stored in a file system or other data store 98 while theappropriate transcoder is loaded. In the example of FIG. 8, the HTTPhandler 94 requests the specified WML→WMLC transcoder from thetranscoder system 86. Although this request is shown in FIG. 8 as anHTTP request from the HTTP handler 94, it should be apparent that othertransfer mechanisms might instead be used by an IP Proxy system 84 toretrieve a transcoder from a remote transcoder system. For example, ifthe IP Proxy system 84 communicates with the transcoder system 86 via aLAN 88 (FIG. 7), then a LAN protocol or data access and transfer schemecould be invoked by the HTTP handler 94 in order to retrieve anyrequired transcoders. In FIG. 8, the transcoder system 86 locates therequested WML→WMLC transcoder among its available transcoders 96 andreturns the requested transcoder to the IP Proxy system 84.

[0097] Regardless of the particular transcoder transfer mechanismimplemented, the IP Proxy system 84, or in the example of FIG. 8 theHTTP handler 94, receives and executes the returned WML→WMLC transcoder,as indicated at 100. The previously received and possibly stored WMLcontent may then be processed by the transcoder 100 to transcode the WMLcontent, and a response containing the transcoded content is returned tothe mobile device 12 by the dispatcher 22.

[0098] If chained transcoder operations are specified in the connectionrequest from the mobile device 12, then more than one transcoder requestmay be made by the IP Proxy system 84 to the transcoder system 86.Multiple transcoders may instead be requested in a single request to thetranscoder system 86. Processing of previously received content forchained transcoder operations may proceed either as each requiredtranscoder is loaded by the IP Proxy system 84, with intermediatetranscoded content possibly being stored in a file system or data storesuch as 98, or only when all required transcoders have been loaded. AnIP Proxy system 84 may also extend the Accept line in an HTTP requestsent to an information source if any of the transcoders available froman external transcoder system can transcode other content types into theinput content type of the specified transcoder, as described above inconjunction with FIG. 6.

[0099] When a transcoding operation is complete, a transcoder loadedfrom the external system 86 is preferably stored locally by the IP Proxysystem 84 in order to avoid subsequent requests to the externaltranscoder system 86 for the same transcoder. Retrieval and loading of atranscoder from a local or internal store in the IP Proxy system 84 willtypically be completed much faster than a request to a remote system andreduces traffic on the communication link between the IP Proxy system 84and the transcoder system 86. In such IP Proxy systems, the activeconnection handler, which is the HTTP handler 94 in FIG. 8, preferablydetermines if a required transcoder is stored in a local data storebefore requesting the transcoder from the external transcoder system 86.Depending upon the amount of available storage, transcoders may bestored indefinitely or for a certain predetermined period of time. Othermemory management schemes, such as over-writing stored transcoders on anLRU basis for example, may also be used when memory resources arelimited.

[0100] The configuration file 92 or transcoder lookup table may beadapted for external transcoder loading by including an indication ofthe location of a transcoder in the configuration file or table entryfor the transcoder. The file 92 or table is preferably updated if atranscoder is stored to, or overwritten in, a local memory, such thatthe active handler can determine from the initial lookup operationwhether or not the transcoder must be loaded from the externaltranscoder system 86. When a transcoder has not been or is no longerstored locally, then the file 92 or lookup table preferably indicatesfrom where the transcoder may be retrieved. For a transcoder that may beretrieved through an HTTP connection, the corresponding file or tableentry may indicate the IP address of the transcoder system 86, whereas anetwork address may be specified in the configuration file or lookuptable when a LAN connection is used. If the location of a transcodersystem from which a specified transcoder is available is known to amobile device 12 or a mobile device user, then the location may also orinstead be included in the connection request from the mobile device.

[0101] It is also contemplated that more than one external transcodersystem may be implemented in a communication system such as 90. In suchan arrangement, the configuration file 92 or lookup table wouldpreferably include entries for all transcoders that are available to anIP Proxy system 84 through all of the external transcoder systems withwhich it can communicate. An IP Proxy system 84 may thereby downloadtranscoders from any of a number of transcoder systems via direct ornetwork connections. Overall operation of an IP Proxy system 84 withmultiple transcoder systems would be substantially as described above,except that different transcoder systems may be accessed, possibly usingdifferent transfer mechanisms and communication protocols, for each datatranscoding operation. Chained transcoding operations may alsopotentially involve communication with different transcoder systems.

[0102] The configuration file 92 or lookup table are preferably arrangedto facilitate a simple resolution scheme when a particular type oftranscoder is available from more than one transcoder system. Althoughan IP Proxy system 84 may be able to access multiple transcoder systems,an owner or administrator of an IP Proxy system 84 may designate one ofthese transcoder systems as a preferred or default system from which theIP Proxy 84 system first attempts to download a transcoder. The order ofpreference of transcoder systems for any transcoder available from morethan one transcoder system may for example be reflected in the order ofconfiguration file or lookup table entries. If the file or table isarranged by transcoder type, then entries corresponding to the mostpreferred sources for a particular transcoder are preferably listedbefore entries associated with other transcoder systems. Theconfiguration file or lookup table may instead be arranged according totranscoder system, with all entries for the default or preferredtranscoder system occurring first. A preferred transcoder system mightalso be specified in a connection request from the mobile device 12. Inthese example arrangements, an IP Proxy system 84 will preferablyattempt to load a particular transcoder from a preferred source beforeaccessing any other sources.

[0103] It should be apparent from the foregoing description that if thespecified transcoder could not be loaded by an IP Proxy system 84, thenan error message may be returned to the mobile device 12 and possiblythe web server 76. Any of the error or failure operations describedabove may be performed by the IP Proxy system 84 and mobile device 12 ifthe specified transcoder could not be used to transcode receivedcontent.

[0104] A data push operation from a push server such as 42 may proceedin a similar manner and therefore will be described only briefly. A pushservices module may either invoke an appropriate connection handler toprocess a push request from a push server or possibly be configured toprocess the request directly. Any transcoder(s) specified in the pushrequest would then be downloaded by the active connection handler orpossibly another connection handler, if required, from the externaltranscoder system 86 or a further transcoder system specified in thepush request. Once downloaded to the IP Proxy system 84, the specifiedtranscoder is invoked to process the content enclosed in the pushrequest. The transcoded content may then be pushed to an intendeddestination mobile device 12 through the dispatcher 22 if any protocoltranslation is necessary. This type of push operation is thussubstantially the same as described above with reference to FIG. 7except that the specified transcoder (or transcoders if chainedtranscoder operations are specified in or allowed for the push request)is downloaded from an external transcoder system. Downloaded transcodersmay be stored by an IP Proxy system 84 in a local store in order toavoid subsequent downloading of the same transcoders. Any of the abovefailure or error processing schemes may also apply to data pushoperations.

[0105]FIG. 10 shows a further signal flow diagram for an externaltranscoder system. In FIG. 10, not only the transcoder system 86, butalso the configuration file 102 is external to the IP Proxy system 84and therefore may be shared among multiple IP Proxy systems.Communications between an IP Proxy system 84 and the configuration file102 may be via a direct connection or a network connection, and may bedifferent for different IP Proxy systems. For example, the configurationfile 102 may be maintained by an owner or operator of a particular IPProxy system 84 which is linked to the configuration file by a directcommunication link, whereas other IP Proxy systems may communicate withthe configuration file 102 through local or wide area networkconnections. The configuration file 102 might also be maintained at thetranscoder system 86. As above, the configuration file 102 may beimplemented as a lookup table. The configuration file 102 may thus beconsidered a registry, with which one or more external transcodersystems such as 86 register available transcoders.

[0106] When an HTTP request specifying a particular transcoder isreceived by the dispatcher 22 in the IP Proxy system 84, it is forwardedto the HTTP handler 94, which as described above determines if thespecified transcoder is available in the IP Proxy system 84. In theexample of FIG. 10 however, the configuration file 102 is remote fromthe IP Proxy system 84. If the configuration file 102 is accessible viaHTTP, then the HTTP handler 94 manages the transcoder lookup functionwith the configuration file 102. If the configuration file 102 is notadapted for HTTP, then a different connection handler may be invoked tofacilitate the transcoder lookup or configuration file search.

[0107] Depending upon the transcoders available to the IP Proxy system84, the HTTP handler 94 may include both the input content type of thespecified transcoder, WML in this example, and any additional contenttypes which may be transcoded into the input content type of thespecified transcoder as accepted content types in the request to theinformation source, illustratively web server 76. The request from theIP Proxy system 84 to the web server 76 therefore includes not only WMLbut also HTML as accepted content types, since HTML can be transcodedinto WML by the HTML→WML transcoder 104 b, which has a correspondingentry in configuration file 102. Either of these content types canultimately be processed by the specified WML→WMLC transcoder.

[0108] As above, it is assumed that the web server 76 from which contentis requested returns WML content to the HTTP handler 94. The transcodingsystem 86 in the example shown in FIG. 10 includes a set of remotelyexecutable transcoders 104, comprising a WML→WMLC transcoder 104 a andan HTML→WML transcoder 104 b, and thereby enables remote transcoding ofcontent. Instead of requesting and loading the WML→WMLC contenttranscoder 104 a from the transcoder system 86, the HTTP handler 94 (oranother connection handler, depending on the particular transcodersystem and the transfer schemes it supports) transfers the WML contentto the transcoding system 86. Within the transcoding system 86, theappropriate WML→WMLC transcoder 104 a is executed and the WML content istranscoded into WMLC format. The WMLC content is then returned to theHTTP handler 94, or to another connection handler if IP Proxy system 84to transcoder system 86 communications do not use HTTP. When the WMLCcontent is returned by the transcoding system 86 and received by theHTTP handler 94, possibly through another connection handler whichcommunicates with the transcoding system 86, it is forwarded to thedispatcher 22. The dispatcher 22 then prepares a response including theWMLC content and sends the response to the mobile device 12. The HTTPhandler 94 may instead prepare the response, which would then betranslated (if necessary) by the dispatcher 22 to conform to acommunication protocol or scheme used by the mobile device.Illustratively, the WML content returned by the web server 76 may bestored by the HTTP handler 94 in case a data transfer or transcodingerror occurs. Local storage of the WML content allows an IP Proxy system84 to re-submit the content, to either the same transcoder system 86 ora different transcoder system, without having to request the contentfrom the web server 76.

[0109] If the requested content is returned by the web server 76 as HTMLcontent, then the HTTP handler 94, through another handler if required,would submit the HTML content to the transcoder system 86 for chainedtranscoding using both the HTML→WML transcoder 104 b and then theWML→WMLC transcoder 104 a specified in the mobile device request. Suchchained transcoding operations may also be specified by the mobiledevice 12 in the connection request. Chained transcoders may either bepart of the same transcoding system 86 as shown in FIG. 10, orimplemented in different transcoder systems. When a chained transcodingoperation involves different transcoder systems, content returned by aninformation source may first be transmitted to one transcoder system fortranscoding into an intermediate content type which is returned to theIP Proxy system 84, and the intermediate content type may then be sentto another transcoder system, for transcoding using the specifiedtranscoder or another intermediate transcoder in a transcoder chain.Content is preferably forwarded between different transcoding systemsvia the IP Proxy system 84 which is processing the connection request,but may instead be directly transmitted from one transcoder system toanother if compatible data transfer mechanisms have been implemented ineach transcoding system.

[0110] Data request errors or failures, such as transcoder errors orother situations in which a specified transcoder is unavailable, may bemanaged according to any of the schemes described above, possiblyincluding such further operations as using a different transcoder totranscode content, returning an error message to the mobile device 12,returning an error message the web server 76, and controlling anysubsequent processing of a request or content from the mobile device 12and/or the web server 76.

[0111] Push operations for systems with one or more externalconfiguration files such as 102 will be apparent from the foregoingillustrative examples. A data push may be accomplished by a push server42 substantially as described above, except that a particular transcoderwould be specified in a push request instead of a request from themobile device 12 as shown in FIG. 10. In addition, a push server 42 mayconsult an external configuration file to determine which transcodersare available to an IP Proxy system 84 before a push request issubmitted. If a required type of transcoder is not available, then thepush server 42 may determine if any other transcoder operation,including chained transcoder operations, may be suitable for the pushrequest and an intended recipient mobile device 12 and format the pushrequest accordingly, thereby possibly avoiding failures or errors at theIP Proxy system 84. As described above, the configuration file 102 maybe a registry including entries for transcoders available from one ormore transcoder systems. When entries in the configuration file 102include an address, such as an IP address, or other identifier of atranscoder system from which a particular transcoder is available, thenthe address may be supplied to an IP Proxy system 84 by a push server 42in a push request. At least some transcoder searching operations maythereby be off-loaded from IP Proxy systems 84 to push servers 42.

[0112] In the system of FIG. 10, it is contemplated that the transcodersystem 86 and configuration file 102 may communicate with each other toensure that the configuration file 102 accurately indicates whichtranscoders are available. A configuration file may be associated with aparticular type of connection such as HTTP connections and thus HTTPconnection handlers. If a configuration file 102 is associated with aparticular transcoder system 86, then the configuration file may beresident within the transcoding system 86.

[0113] If multiple transcoding systems are implemented, a sharedconfiguration file storing transcoder entries for the transcodersavailable in all transcoder systems 84 may simplify the transcoderlookup performed by a connection handler. An IP Proxy system 84 or pushserver 42 need then only consult a single configuration file todetermine if appropriate transcoders are available from any transcodersystems with which it can communicate. This single configurationfile/server could also support protocols to allow external transcodingservers to register. A registration process could add a list ofavailable transcoders to the single configuration file, for example.

[0114] An external transcoding system 86 preferably supports a queryfunction to allow a mobile device 12 or a push server 42 to determinewhich transcoders are available before a connection request is preparedand sent to an IP Proxy system 84. Some mechanism whereby transcoderscan be added to the transcoder system 86 and configuration file 102would also preferably be supported. A push server 42 may then add a newtranscoder to the transcoding system 86 and push content that relies onthe new transcoder to mobile devices such as mobile device 12 through anIP Proxy system 84.

[0115] External transcoder systems 86 include download systems fromwhich transcoders may be downloaded by an IP Proxy system 84 andexecuted locally (see FIG. 9) and remote transcoding systems to whichcontent is sent for transcoding at the transcoding system (see FIG. 10).In another embodiment, a “hybrid” transcoder system incorporatingaspects of both these types of transcoder systems. When a hybridtranscoder system is available to an IP Proxy system 84, the IP Proxysystem 84 may either download a required transcoder from the transcodersystem or send content to the transcoder system to be transcodedremotely. The selection of transcoder download or remote transcoding maybe dependent, for example, upon the amount of data to be transcoded, thecomplexity of the transcoding (single or chained operations), or othercriteria. Similarly, chained transcoding operations may involve downloadtranscoding systems and local transcoder execution as well as remotetranscoding systems.

Example Implementation

[0116] An example implementation of an IP Proxy system will now bedescribed. FIG. 11 is a block diagram showing an IP Proxy systemimplemented in a secure network.

[0117] The system 120 in FIG. 11 includes a mobile device 12 thatoperates within a wireless network 14. Through a gateway 15, the mobiledevice can receive and preferably also send data over a WAN 16 such asthe Internet. These elements of the system 120 are substantially thesame as similarly labelled elements in FIG. 1. In the system 120however, the IP Proxy system 124 is configured within a private networksuch as a corporate network 130, behind a security firewall 127, andcommunicates with the gateway 15 through a network server computer 122.In a particular example embodiment, the network server 122 is associatedwith an email system 128. Two information sources, an internal source126 and an external source 132, are also shown in FIG. 11.

[0118] The network server 122 preferably enables secure communication tothe mobile device 12, as indicated by the encryption and decryptionblocks 122 a and 122 b. The network server 122 encrypts anycommunications directed to a mobile device 12. The intended recipientmobile device 12, using a secret key stored therein, can decryptencrypted communications from the network server 122. A mobile device 12similarly encrypts any information sent to the network server 122, whichcan be decrypted by the decryption module 122 b. Those skilled in theart of cryptography will appreciate that the keys and encryptionalgorithms used at the network server 122 and mobile device 12 arepreferably chosen so that it would be computationally infeasible todecrypt encrypted information without the required secret key. Onepreferred encryption scheme is triple-DES (Data Encryption Standard).

[0119] Key distribution between a network server 122 and a mobile device12 may be accomplished via a secure connection such as a secure physicalconnection between the mobile device 12 and the network server 122, orbetween the mobile device 12 and another computer within the corporatenetwork. Known public key cryptography techniques may instead be usedfor key distribution. In a public key scheme, a public key is used toencrypt information in such a way that the encrypted information may bedecrypted using a corresponding private key. The public key is storedby, and may be retrieved from, a publicly accessible key repositorycommonly referred to as a certificate authority or CA, whereas theprivate key is stored only at a mobile device or system with which thepublic key is associated. Thus, a network server 122 or any other senderthat wishes to send encrypted information to a mobile device 12 mayretrieve the mobile device's public key from a CA and use the public keyto encrypt information destined for the mobile device 12. A mobiledevice 12 may similarly obtain a network server's public key from a CAand use the public key to encrypt communication signals to be sent tothe server.

[0120] Regardless of the particular key distribution scheme andencryption techniques used, encrypted communications between a mobiledevice 12 and network server 122 allows for secure access to corporateor other private information using a mobile device 12. Consider theexample of the internal information source 126 within the securityfirewall 127, described below with reference to FIG. 12. FIG. 12 is asignal flow diagram illustrating a corporate data access operation. Inkeeping with the above illustrative example operations, FIG. 12 shows anHTTP-based data access operation.

[0121] In FIG. 12, an HTTP request is encrypted at the mobile device 12,preferably using a strong encryption routine such as triple-DES (3DES),before it is sent to the network server 122 through the wireless network14 (FIG. 11) and possibly other intermediate networks or components likethe gateway 15 and WAN 16 shown in FIG. 11. The encrypted request isthen received by the network server 122 and decrypted in the decryptionmodule 122 b. The decrypted request is forwarded to the IP Proxy system124, which may proceed to process the request substantially as describedabove. The active handler, the HTTP handler 26 in this example, mayconsult the configuration file 72 or transcoder lookup table and expandthe accepted content types to include content types that can betranscoded into the format(s) that can be accepted by the mobile device12. A request, possibly including further content types, is then sent bythe HTTP handler 26 to the information source 126, which then returnsrequested information, in WML format in this example. An appropriatetranscoder 74 is loaded and invoked by the HTTP handler 26 if necessaryand the requested content, preferably in a format requested by themobile device 12, is returned to the network server 122 through thedispatcher 22. The network server 122 then encrypts the content receivedfrom the IP Proxy system 124 in its encryption module 122 a and sendsthe encrypted content in a response to the mobile device 12. In someimplementations, the protocol conversion or translation operationsassociated with the dispatcher 22 may instead be performed by thenetwork server 122.

[0122] The information source 126 may be a computer system or data storepreferably configured for operation on the private network 130, such asa file server or other data store accessible through the network 130. Inthe example of a corporate network, the information source 126 mayinclude confidential or otherwise sensitive information that an owner ofthe network 130 strives to keep private. The security firewall 127 isintended to prevent unauthorized access to private network componentsincluding the information source 126. In some situations, the veryexistence of information stored at the information source must remainconfidential. The encryption of the request from the mobile device asshown in FIG. 12 prevents an unauthorized party from determining thecontents of the request without breaking the encryption, which asdescribed above is not computationally feasible for strong encryptionschemes such as 3DES. The request remains encrypted until received bythe network server 122 and decrypted, behind the security firewall 127,as indicated at 134 in FIG. 12. The request is therefore virtually assecure as a request sent from a computer system on the network 130.

[0123] Once decrypted, the request is processed by the IP Proxy system124 and information source 126 as described above. However, encryptionof the requested content by the encryption module 122 a in the networkserver 122 before it is sent to the mobile device 12 similarly ensuresthat the content can only be viewed by the mobile device 12.Confidential corporate information therefore remains encrypted and thussecure until received and decrypted at the mobile device 12, therebyeffectively extending the security firewall to the mobile device 12.Both the request and the information returned to the mobile device inresponse thereto are secure.

[0124] In known remote data access schemes such as WAP, gateway systemswhich provide for data access using mobile devices are normally locatedoutside corporate or private premises, at the location of a serviceprovider for example. Any confidential or sensitive informationencrypted at the private premises is decrypted at the gateway system,outside the corporate firewall, and then re-encrypted before being sentto the destination mobile device or devices. The information istherefore in the clear at the gateway system and thus accessible by anowner or operator of the gateway system. Furthermore, the owner oroperator of a private network from which the information was senttypically has no control over security arrangements at the gatewaysystem, such that the information is vulnerable to attacks on thegateway system.

[0125] The arrangement shown in FIGS. 11 and 12 provides for secureremote access to private, confidential or otherwise sensitiveinformation. Information is encrypted from end-to-end between thenetwork server 122 and any mobile device 12. Any level of security maybe implemented at the security firewall 127 to protect confidentialinformation stored at an information source such as 126, and whenencrypted by the network server 122, information is not decrypted at anyintermediate point before being received at a mobile device 12. Theinformation is in the clear only “inside” the point 134, behind thesecurity firewall 127, and on the mobile device. Security arrangementssuch as password or passphrase control are also preferably implementedat the mobile device 12 to prevent an unauthorized user from using themobile device 12 or decrypting received encrypted information. Forexample, computer workstations may be protected by password-deactivatedsystem locking and access to a corporate network 130 is normallyprotected by login passwords. Similarly, a password may be required touse a mobile device 12, while a different passphrase may be necessary todecrypt any encrypted information stored on the mobile device. A mobiledevice 12 and information stored thereon is thereby just as secure as anetwork workstation and information stored on a network. Such techniquesas limited password or passphrase entry retries, mobile device 12 ormobile device memory reset after a predetermined number of failedpassword/passphrase entries, dynamic and possibly randompassword/passphrase updates and the like may be used to further improvemobile device security.

[0126] For an external information source 132 (FIG. 11), a data accessoperation is substantially the same as shown in FIG. 12, except that theinformation source is outside the firewall 127. The request and responseexchange between the mobile device 12 and the network server 122 may beencrypted, but information exchanged with the information source 132 maybe unsecure. If the information provided by the information source 132is not private or confidential, then unsecure exchange between the IPProxy system 124 and the source 132 will be sufficient for mostpurposes. However, if the external source 132 provides privateinformation, then alternate arrangements are preferably provided.

[0127] One possible measure to improve the security of information beingrequested from an external source 132 is to secure the communicationsbetween the IP Proxy system 124 and the source 132. For example, the IPProxy system 124 may be adapted to support Secure HTTP (HTTPS), SecureSockets Layer (SSL) or other secure communication schemes in order tosecurely access information at the information source 132. Informationfrom the source 132 may thereby be securely transferred to the IP Proxysystem 124 and is then protected by the security firewall 127. Encryptedinformation may be decrypted by the IP Proxy system 124, by the activeconnection handler for example, and transferred to the network server122, which then encrypts the information for transmission to the mobiledevice 12. As above, information is only in the clear behind thefirewall 127. Alternatively, a secure communication session may beestablished between the mobile device 12 and source 132 through the IPProxy system 124. In the system of FIG. 11, communications between themobile device 12 and network server 122 would then be double-encrypted.

[0128] As shown in FIG. 11, the network server 122 is also associatedwith the email system 128. In one embodiment, the network server 122provides redirection of data items from the email system 128 to mobiledevice 12. One such system is described in detail in U.S. Pat. No.6,219,694, entitled “System And Method For Pushing Information From AHost System To A Mobile Data Communication Device Having A SharedElectronic Address”, and issued to the assignee of the presentapplication on Apr. 17, 2001. The complete disclosure of this patent ishereby incorporated into this application by reference.

[0129] Since the network server 122 is also associated with the IP Proxysystem 124, integrated functionality between the email system 128 andthe IP Proxy system 124 may be possible. In one embodiment, the IP Proxysystem 124 uses encryption functionality of the network server 122 aswell as a transport mechanism via which the network server 122communicates with the mobile device 12. Other functions of the networkserver 122, such as data compression for example, may similarly beexploited by an IP Proxy system 124 to improve the efficiency of use ofwireless communication resources. As described briefly above, contentdestined for a mobile device 12 may be addressed to the mobile deviceusing an email address in the email system 128 associated with themobile device user. In this example, content forwarded to the mobiledevice 12 by the IP Proxy system 124 may also be stored in the user'smailbox on email system 128 by the network server 122, as indicated inFIG. 11, to thereby provide both a record of IP Proxy system operationsand a stored copy of any forwarded content. Other integrated functionsmay include but are in no way limited to email-based content requestsfrom mobile devices and addressing of mobile device-destined informationby the IP Proxy system 124 using an email address on the email system128. Still further integrated functions may be enabled where a networkserver 122 or the IP Proxy system 124 is associated with any otherservices.

[0130] It will be appreciated that the above description relates toexemplary embodiments by way of example only. Many variations on theinvention will be apparent to those of ordinary skill in the art, andsuch variations are within the scope of the invention as described,whether or not expressly described.

[0131] For example, embodiments of the invention have been describedprimarily in the context of an IP-based system. Similar proxy systemsfor other types of communication systems are also contemplated withinthe scope of the invention. Other types of connections, connectionhandlers and transcoders than those described above will also beapparent to those skilled in the art.

[0132] Depending upon the particular implementation of a remote dataaccess system and the features to be supported, not all of the elementsshown in FIG. 2 are required. Where push services are not supported forexample, the proxy system will not include push services 30.

[0133] The instant invention is also in no way limited to content typeindication using MIME types. MIME types are useful in conjunction withthe instant invention, but are not required to practice the invention.Other content type indicators may be substituted for MIME type toindicate the type or format of requested or received content.

[0134] Although the transcoders described above convert betweenwell-known information types or formats, custom transcoders could bedeveloped and implemented for virtually any information format,including for example application program file types and proprietaryformats. As described above, a proxy system in accordance with theinstant invention is preferably configurable and new content transcodersmay be added.

[0135] It is also possible that information content from an informationsource may include multiple different content types, not just a singlecontent type as described above. For such multiple-type content,transcoders may be selected, for example, to transcode the content intoa single content type, or into multiple content types accepted at amobile device. In the case of transcoder selection by a mobile device orinformation source as described above, a list of transcoders for any oreach part of multiple-type information type content may be specified ina connection request, a response to a request, or a push request. Arespective transcoder may be specified and used for each part of theinformation content having a particular content type. Respectivetranscoders may be selected for each of the multiple content types basedon different selection schemes. For example, when the multiple contenttypes include a first content type and a second content type, atranscoder may be specified for the first content type, whereas atranscoder for the second content type may be selected based on a typeor identifier of a mobile device or information source.

[0136] When any part of multiple-type information content cannot betranscoded as specified, where a specified transcoder is not availablefor example, only other parts of the information content might betranscoded and sent to a mobile device. Alternatively, a defaulttranscoding operation as described above may be used to transcode partsof multiple-type content. Non-transcoded parts of multiple-type content,or possibly all of the multiple-type content, could instead be replacedwith a link or other information that may be used to subsequently accessthe information content or parts thereof, and sent to a mobile device.Information indicating the multiple content types and/or required orrecommended transcoders could also be sent to the mobile device. Theinformation content or parts thereof may then be retrieved by the mobiledevice by submitting a connection request or possibly furthertranscoding instructions or an alternate transcoder selection to an IPProxy system.

[0137] Furthermore, a proxy system may be implemented in any network,not only in a corporate network as shown in FIG. 11. Installation of aproxy system in an ISP, ASP, or Virtual Network Operator (VNO) systemwould provide for secure remote access to network information and securetransfer of information between any network users, including transfersbetween mobile devices of ISP, ASP or VNO users.

[0138] Although the invention has been described in detail withreference to certain illustrative embodiments, variations andmodifications exist within the scope and spirit of the invention asdescribed and defined in the following claims.

What is claimed is:
 1. A system for providing information content over anetwork to a wireless mobile communication device, comprising: atranscoding system comprising a plurality of transcoders, eachtranscoder operable to transcode the information content from arespective input content type into a respective output content type; anda first network device in communication with the transcoding system andcomprising a connection handler system, the first network deviceoperable to receive a first connection request comprising transcoderrequest data and to select a corresponding connection handler operableto select one or more transcoders from the plurality of transcodersbased on the transcoder request data.
 2. The system of claim 1, whereinthe first network device is further operable to transmit the informationcontent transcoded into an output content type to the wireless mobilecommunication device.
 3. The system of claim 1, wherein the transcodingsystem is further operable to transmit the information contenttranscoded into an output content type to the wireless mobilecommunication device.
 4. The system of claim 1, wherein the transcoderrequest data identifies a requested transcoder.
 5. The system of claim4, wherein the transcoding system comprises a configuration fileassociated with the plurality of transcoders, and the connection handleris operable to search the configuration file to determine whether therequested transcoder is one of the plurality of transcoders and toselect the requested transcoder where the requested transcoder is one ofthe plurality of transcoders.
 6. The system of claim 5, wherein theconnection handler is further operable to transmit an error message tothe wireless mobile communication device where the requested transcoderis not one of the plurality of transcoders.
 7. The system of claim 6,wherein the connection handler is further operable to receive alternatetranscoder request data in response to the error message, the alternatetranscoder request data identifying an alternate transcoder.
 8. Thesystem of claim 5, wherein the connection handler is further operable totransmit a list of selectable transcoders to the wireless mobilecommunication device where the requested transcoder is not one of theplurality of transcoders.
 9. The system of claim 8, wherein theconnection handler is operable to receive selected transcoder data fromthe wireless mobile communication device and to select one of theselectable transcoders from the list of selectable transcoders based onthe selected transcoder data.
 10. The system of claim 5, wherein theconnection handler is further operable to discard the informationcontent where the requested transcoder is not one of the plurality oftranscoders.
 11. The system of claim 5, wherein the connection handleris further operable to pass the information content where the requestedtranscoder is not one of the plurality of transcoders.
 12. The system ofclaim 5, wherein the transcoding system is further operable to transcodethe information content into a content type forwarded to the wirelessmobile communication device in response to a previous connection requestwhere the requested transcoder is not one of the plurality oftranscoders.
 13. The system of claim 4, wherein the connection handleris further operable to determine whether the requested transcoder is oneof the plurality of transcoders, and, where the requested transcoder isnot one of the plurality of transcoders, to determine a type of thewireless mobile communication device and to select one or moretranscoders from the plurality of transcoders based on the type of thewireless mobile communication device.
 14. The system of claim 4, whereinthe connection handler is further operable to determine whether therequested transcoder is one of the plurality of transcoders, and, wherethe requested transcoder is not one of the plurality of transcoders, todetermine an address associated with the wireless mobile communicationdevice and to select one or more transcoders from the plurality oftranscoders based on the address of the wireless mobile communicationdevice.
 15. The system of claim 4, wherein the information contentoriginates at an information source, and wherein the connection handleris further operable to determine whether the requested transcoder is oneof the plurality of transcoders, and, where the requested transcoder isnot one of the plurality of transcoders, to determine an address of theinformation source and to select one or more transcoders from theplurality of transcoders based on the address of the information source.16. The system of claim 1, wherein the transcoder request data comprisesa list of one or more accepted content types in order of preference. 17.The system of claim 16, wherein the connection handler is operable toselect from the plurality of transcoders based on the order ofpreference of the list of one or more accepted content types.
 18. Thesystem of claim 1, wherein the connection handler is further operable totransmit a list of selectable transcoders to the wireless mobilecommunication device upon receiving the transcoder request data, toreceive selected transcoder data from the wireless mobile communicationdevice, and to select one or more of the selectable transcoders from thelist of selectable transcoders based on the selected transcoder data.19. The system of claim 1, wherein the transcoder request data comprisesa network address specifying the location of a transcoder.
 20. Thesystem of claim 19, wherein the transcoding system is operable to accessthe location specified by the network address, to retrieve thetranscoder, and to store transcoder data associated with the transcoderin a configuration file.
 21. The system of claim 1, wherein thetranscoding system is operable generate and store mapping datacomprising transcoding chains, each transcoding chain selecting one ormore of the plurality of transcoders to transcode the informationcontent from a respective input content type into a respective outputcontent type.
 22. The system of claim 21, wherein the transcoding systemcomprises a configuration file including transcoder data associated withthe plurality of transcoders, and wherein the mapping data is updatedupon the addition or deletion of transcoder data.
 23. The system ofclaim 21, wherein the connection handler is further operable to select atranscoding chain to transcode the information content from the inputcontent type into the output content type based on user definedcriteria.
 24. The system of claim 23, wherein the user defined criteriaincludes data priority and time priority.
 25. The system of claim 1,wherein: the information content includes multiple content types; andthe transcoder request data identifies a respective requested transcoderfor at least one of the multiple content types.
 26. A method forproviding information content over a network to a mobile communicationdevice, comprising the steps of: receiving a connection requestincluding a transcoder request for a requested transcoder; establishinga connection with an information source responsive to the connectionrequest; receiving information content from the information source;providing a plurality of transcoders, each transcoder configured totranscode information content from a respective input content type intoa respective output content type; selecting one or more transcoders fromthe plurality of transcoders based on the transcoder request;transcoding the information content using the one or more transcodersselected to generate transcoded information; and sending the transcodedinformation content to the mobile communication device.
 27. The methodof claim 26, wherein the step of receiving a connection requestcomprises the step of receiving a connection request from the mobilecommunication device.
 28. The method of claim 26, wherein the connectionrequest identifies the information source.
 29. The method of claim 26,wherein the step of selecting one or more transcoders from the pluralityof transcoders based on the transcoder request comprises the steps of:determining whether the requested transcoder is one of the plurality oftranscoders; selecting the requested transcoder where the requestedtranscoder is one of the plurality of transcoders; and where therequested transcoder is not one of the plurality of transcoders:determining a requested output content type of the requested transcoder;determining a received content type of the information content; andselecting one or more transcoders to transcode the information contentfrom the received content type to the requested output content type. 30.The method of claim 26, wherein the step of establishing a connectionwith an information source responsive to the connection requestcomprises the step of sending an information request to the informationsource.
 31. The method of claim 30, wherein the connection requestidentifies one or more accepted content types.
 32. The method of claim31, further comprising the steps of: determining whether any of theplurality of transcoders are configured to transcode any further contenttypes into any of the one or more accepted content types where therequested transcoder is not one of the plurality of transcoders; andincluding the one or more accepted content types and the further contenttypes in the information request.
 33. The method of claim 32, whereinthe step of determining whether any of the plurality of transcoders areconfigured to transcode any further content types into any of the one ormore accepted content types where the requested transcoder is not one ofthe plurality of transcoders comprises the steps of: determining arequested output content type of the requested transcoder; and comparingthe requested output content type to the respective output content typesof each of the plurality of transcoders.
 34. The method of claim 26,further comprising the steps of: determining whether the requestedtranscoder is one of the plurality of transcoders; and discarding theinformation content where the requested transcoder is not one of theplurality of transcoders.
 35. The method of claim 26, further comprisingthe steps of: determining whether the requested transcoder is one of theplurality of transcoders; and performing a default transcoding operationon the information content where the requested transcoder is not one ofthe plurality of transcoders.
 36. The method of claim 35, wherein thedefault transcoding operation comprises the step of passing theinformation content.
 37. The method of claim 35, wherein the defaulttranscoding operation comprises the step of transcoding the informationcontent into a content type forwarded to the mobile communication devicein response to a previous connection request.
 38. The method of claim26, further comprising the step of transmitting a list of selectabletranscoders to the mobile communication device where the requestedtranscoder cannot be selected.
 39. The method of claim 35, furthercomprising the step receiving another connection request where therequested transcoder cannot be selected, the other connection requestcomprising an alternate transcoder request.
 40. The method of claim 26,wherein the transcoder request comprises a network address specifyingthe location of the requested transcoder, and the step of selecting oneor more transcoders from the plurality of transcoders based on thetranscoder request comprises the steps of: accessing the locationspecified by the network address; and retrieving the requestedtranscoder.
 41. The method of claim 26, wherein the step of transcodingthe information content using the one or more transcoders selectedcomprises the steps of: transcoding the information content into anintermediate content type; and transcoding the information content fromthe intermediate format into a final content type.
 42. The method ofclaim 26, wherein the step of transcoding the information content usingthe one or more transcoders selected comprises the steps of: sending theinformation content to a transcoding system; and receiving thetranscoded information content from the transcoding system.
 43. Themethod of claim 26, wherein the step of sending the transcodedinformation content to the mobile communication device comprises thestep of encrypting the transcoded information content.
 44. The method ofclaim 26, wherein the step of sending the transcoded information contentto the mobile communication device comprises the step of compressing thetranscoded content.
 45. The method of claim 26, wherein the informationsource is a private information source configured to operate within aprivate computer network behind a security firewall.
 46. The method ofclaim 26, further comprising of steps of: determining whether therequested transcoder is one of the plurality of transcoders; and wherethe requested transcoder is not one of the plurality of transcoders:receiving a list of transcoders according to an order of preference; andselecting one or more of the transcoders in the list of transcodersbased on the order of preference.
 47. The method of claim 26, furthercomprising of steps of: determining whether the requested transcoder isone of the plurality of transcoders; and where the requested transcoderis not one of the plurality of transcoders: determining a type of themobile communication device; and selecting one or more of the pluralityof transcoders based on the type of the mobile communication device. 48.The method of claim 26, further comprising of steps of: determiningwhether the requested transcoder is one of the plurality of transcoders;and where the requested transcoder is not one of the plurality oftranscoders: determining an identifier associated with the mobilecommunication device; and selecting one or more of the plurality oftranscoders based on the identifier.
 49. The method of claim 26, furthercomprising the steps of: determining whether the requested transcoder isone of the plurality of transcoders; and where the requested transcoderis not one of the plurality of transcoders: determining an identifierassociated with the information source; and selecting one or more of theplurality of transcoders based on the identifier.
 50. The method ofclaim 26, wherein: the information content comprises multiple contenttypes; the step of selecting one or more transcoders comprises the stepof selecting a respective transcoder for at least one of the multiplecontent types.
 51. The method of claim 50, wherein the multiple contenttypes comprise at least a first content type and a second content type,wherein the transcoder request identifies a requested transcoder for thefirst content type, and wherein the step of selecting one moretranscoders comprises the steps of: selecting the requested transcoderfor the first content type; and selecting at least one of the pluralityof transcoders for the second content type.
 52. The method of claim 51,wherein the step of selecting at least one of the plurality oftranscoders for the second content type comprises the step of selectingat least one of the plurality of transcoders for the second content typebased on the respective input content type of the plurality oftranscoders.
 53. The method of claim 51, wherein the step of selectingat least one of the plurality of transcoders for the second content typecomprises the step of selecting at least one of the plurality oftranscoders for the second content type based on a type of the mobilecommunication device.
 54. The method of claim 51, wherein the step ofselecting at least one of the plurality of transcoders for the secondcontent type comprises the step of selecting at least one of theplurality of transcoders for the second content type based on an addressof the information source.
 55. The method of claim 26, wherein therespective output content types include one or more content typesselected from the group consisting of Wireless Markup Language (WML),Hypertext Markup Language (HTML), compiled WML (WMLC) and ExtensibleMarkup Language (XML).
 56. A system for providing remote data access toa mobile communication device, comprising: means for receiving aconnection request, the connection request comprising a transcoderrequest for a requested transcoder; means for establishing a connectionwith an information source responsive to the connection request; meansfor receiving information content from the information source; means forproviding a plurality of transcoders and for transcoding the informationcontent using one or more of the plurality of transcoders, eachtranscoder being configured for transcoding information content from arespective input content type into a respective output content type;means for selecting the requested transcoder from the plurality oftranscoders based on the transcoder request; and means for sending thetranscoded information content to the mobile communication device. 57.The system of claim 56, wherein the means for receiving a connectionrequest comprises means for receiving a connection request from themobile communication device.
 58. The system of claim 57, wherein theconnection request identifies the information source and the informationcontent.
 59. The system of claim 58, wherein the connection requestidentifies the information source using a network address.
 60. Thesystem of claim 56, wherein the means for establishing a connection withan information source responsive to the connection request comprisesmeans for sending an information request to the information source. 61.The system of claim 60, wherein the connection request identifies one ormore accepted content types.
 62. The system of claim 61, wherein: themeans for selecting the requested transcoder from the plurality oftranscoders based on the transcoder request comprises means fordetermining whether any of the plurality of transcoders are configuredto transcode any further content types into any of the one or moreaccepted content types; and the means for establishing a connection withan information source responsive to the connection request is furtheradapted for including the one or more accepted content types and thefurther content types in the information request.
 63. The system ofclaim 62, wherein the means for determining whether any of the pluralityof transcoders are configured to transcode any further content typesinto any of the one or more accepted content types comprises means forsearching the plurality of transcoders for transcoders configured totranscode information content into the accepted content types.
 64. Thesystem of claim 56, wherein the means for selecting the requestedtranscoder from the plurality of transcoders based on the transcoderrequest comprises means for discarding the information content where therequested transcoder cannot be selected.
 65. The system of claim 56,wherein the means for providing a plurality of transcoders and fortranscoding the information content using one or more of the pluralityof transcoders comprises means for performing a default transcodingoperation on the information content where the requested transcodercannot be selected.
 66. The system of claim 56, wherein: the informationcontent comprises multiple parts having respective content types; andthe connection request comprises a transcoder request for respectiverequested transcoders for at least one of the respective content types.67. The system of claim 66, wherein the means for selecting therequested transcoder comprises means for performing a defaulttranscoding operation on any of the multiple parts of the informationcontent for which the respective requested transcoder cannot beselected.
 68. The system of claim 64, wherein the default transcodingoperation passes the information content.
 69. The system of claim 64,wherein the default transcoding operation transcodes the informationcontent into a content type forwarded to the mobile communication devicein response to a previous connection request.
 70. The system of claim56, further comprising means for transmitting a list of selectabletranscoders to the mobile communication device where the requestedtranscoder cannot be selected.
 71. The system of claim 56, wherein thetranscoder request comprises a network address specifying the locationof the requested transcoder, and the means for selecting the requestedtranscoder from the plurality of transcoders based on the transcoderrequest comprises means for accessing the location specified by thenetwork address and for retrieving the requested transcoder.
 72. Thesystem of claim 56, wherein the means for providing a plurality oftranscoders and for transcoding the information content using one ormore of the plurality of transcoders comprises means for transcoding theinformation content into an intermediate format and for transcoding theinformation content from the intermediate format into a final format.73. The system of claim 56, wherein the means for providing a pluralityof transcoders and for transcoding the information content using one ormore of the plurality of transcoders comprises: means for sending theinformation content to a transcoding system; and means for receivingtranscoded information content from the transcoding system.
 74. Thesystem of claim 56, further comprising means for encrypting thetranscoded information content.
 75. The system of claim 60, wherein theinformation request includes the respective input content type and therespective output content type of the requested transcoder.
 76. A systemfor providing information content over a network, comprising: a mobilecommunication device operable to transmit a first connection requestover the network, the first connection request comprising transcoderrequest data identifying a requested transcoder; wherein the requestedtranscoder is operable to transcode the information content into acontent type that is accepted by the mobile communication device. 77.The system of claim 76, wherein the transcoder request data furthercomprises a network address specifying the location of the requestedtranscoder.
 78. The system of claim 76, wherein the transcoder requestdata further comprises a list of alternate transcoders, each alternatetranscoder operable to transcode the information content into a contenttype that is accepted by the mobile communication device.
 79. The systemof claim 76, wherein the transcoder request data further comprises alist of acceptable content types in order of preference, and wherein therequested transcoder is operable to transcode the information contentinto a content type corresponding to the acceptable content type firstin the order of preference.
 80. The system of claim 76, wherein thetranscoder request data further comprises user priorities including highdata priority and high time priority.
 81. The system of claim 76,wherein the mobile communication device is further operable to encryptthe first connection request prior to transmitting the first connectionrequest over the network.